「頑張っているのに評価されない」エンジニアへ。なぜ評価会議をハックするにはセルフブランディングが不可欠なのか
「こんなに開発タスクをこなして、深夜までリファクタも進めたのに、なぜか評価が上がらない」 「自分より技術力で劣っているように見える同僚が、なぜか上のグレードに昇格していく」
現場でエンジニアをしていると、一度はこうした不満や疑問を感じたことがあるのではないでしょうか。
結論から言うと、どれだけ手を動かして汗をかいていても、「自分自身の満足の範囲」で完結している努力は、組織における評価には結びつきません。
評価とは本質的に「他者が決めるもの」です。いくら自分が「良い仕事をした」と確信していても、評価権を持つ他者から「良い仕事をしている」と認知され、合意されなければ、存在しないのと同じなんですよね。
本稿では、エンジニアが組織の中で適切に、あるいはそれ以上に評価を勝ち取るために不可欠な「セルフブランディング」の構造と、評価会議（キャリブレーション）のリアルについて掘り下げていきます。
1. 「自己満足の頑張り」が評価されないメカニズム
「コードをたくさん書いた」「難しい技術的負債を解消した」「誰も気づいていなかったバグを直した」。 これらはエンジニア個人としては非常に誇らしい実績ですし、技術者としての誠実さの表れでもあります。
しかし、これらが評価の場で期待通りの高評価に繋がらないからといって、評価者が不当に扱っているわけではありません。評価する側からすれば、極めてロジカルに判断した結果であることがほとんどです。その根底にあるのは、個人と組織の間における「成果」の定義の圧倒的なズレです。
個人は、自分の守備範囲や技術的なこだわり、日々のタスクをどれだけやりきったかという基準で「成果」を捉えます。一方で、評価する側は、会社の利益や事業の成長にどう寄与したかという基準で評価を行います。
評価者側はあくまで「事業や組織へのインパクト」という共通基準に照らし合わせて正当にジャッジしているにすぎません。だからこそ、どれだけ個人が「良い仕事をした」と自負していても、それが事業の利益に結びつく文脈で語られなければ、評価する側から見れば「自己満足の範囲で閉じた活動」と判断されてしまうのです。
エンジニアリングマネージャー（EM）であっても、チーム全員のプルリクエストを細部まで把握し、誰がどれだけ裏方で苦労したかを100%拾い上げるのは不可能です。ましてや、評価を最終決定する部長や役員クラスからすれば、あなたの日常の苦労など解像度ゼロに等しいのが現実です。
「成果を出していれば、誰かが見てくれているはずだ」という期待は、この「成果の定義のズレ」を見落としているがゆえに生まれます。周囲に伝わる形に、あるいは事業の利益に結びつく文脈に変換していない活動は、評価者の視界には「評価すべき成果」として入ってこないのです。
2. 評価考課のリアル：決定権は「合議」にある
セルフブランディングの重要性を理解するには、評価が決定される現場、いわゆる「評価調整会議（キャリブレーション）」の力学を知る必要があります。
多くのIT企業において、エンジニアの昇格や評価ランクは直属の上司の一存だけでは決まりません。他チームのEMやテックリード、部門長が一堂に会し、各メンバーの評価を持ち寄って議論する合議制が一般的です。
この場で起きるリアルな会話は、おおよそ次のようなものです。
直属のEM：「うちのAさんは今期、決済モジュールのリアーキテクチャを完遂し、非常に高い成果を出しました。S評価をつけて昇格させたいです」
他チームのEM-X：「うーん、その成果って他チームへの波及効果はあったんですか？ 私のところからは、普段何をやっているのかあまり見えてこないんですよね……反対とまでは言いませんが、S評価の枠は限られているので、より全社的な影響力が見えるBさんを優先すべきでは？」
ここで直属の上司がどれだけ熱弁を振るっても、周囲のマネージャー陣があなたの働きを知らなければ、「他チームへのインパクトが不明瞭」「再現性が確認できない」といった理由で反対意見が出たり、相対評価の煽りを受けてランクを落としたりします。
ブランディングが「反対意見」を無力化する
もし日頃から社内でのセルフブランディングが成立していたらどうなるでしょうか。
Slackのパブリックチャンネルでの技術発信、社内勉強会でのLT、他チームを巻き込んだ障害振り返り（ポストモーテム）などを通じて、「Aさんは決済周りとリアーキテクチャのプロであり、組織のボトルネックを解消してくれる人だ」という認識が他チームのEMにも浸透していたとします。
その場合、評価会議の空気は一変します。
直属のEM：「AさんをS評価に推薦します」
他チームのEM-X：「いや、そこまで目立った動きだったかな……？」
他チームのEM-Y：「あ、でもAさんは先日うちのチームのインシデント時にも決済基盤の設計ドキュメントをもとに的確なフォローをしてくれましたよ。全社的にもかなり助けられています」
他チームのEM-Z：「うちの若手もAさんの社内勉強会資料を参考にして設計を進めていましたね。納得感あります」
このように、たとえ1人が反対や慎重論を唱えたとしても、他の評価者が賛成に回る構図が自然と生まれます。日頃から培ってきたブランディングそのものが、合議制の場であなたを守り、引き上げる「外堀」として機能するわけです。
3. 「レベル感のコントロール」を怠ると即死する
セルフブランディングの話をすると、「要するに社内政治やアピール合戦のことか」「中身のない人間が得をするシステムなのか」と嫌悪感を示すエンジニアが必ずいます。
しかし、それはブランディングではなく単なる「虚飾」です。ここで絶対に外してはならないのが、実力と見せ方の「レベル感のコントロール」です。
実力が50しかないのに、ブランディングによって100に見せかけるような過大広告を行えば、一時的に評価を掠め取ることはできるかもしれません。しかし、ソフトウェア開発はコードとシステムという動かぬ証拠が残る世界です。実力以上のゲタを履かせたブランディングは、重要な局面で任されたタスクの破綻によって、一瞬でメッキが剥がれます。その後に待っているのは「口だけ動いてデリバリーできないエンジニア」という最悪のレッテルです。
目指すべきは、「実力値が80あるなら、他者から見ても過不足なく80（あるいは85〜90程度の期待値）に見える状態を作ること」です。
多くの真面目なエンジニアは、実力が80あるにもかかわらず、発信を怠るせいで周囲から30や40にしか見えていません。このギャップを埋めることこそが、エンジニアにおける健全なセルフブランディングです。
4. この戦略が機能する前提条件
この「セルフブランディングによる評価獲得」というアプローチには、明確な前提条件があります。自社の評価制度がどこに主眼を置いているかを見極めなければなりません。
通用しない環境：純粋な「絶対的成果主義」
KPIが完全に定量化されており、「売上を〇億円達成したか」「特定機能のコンバージョンを〇%改善したか」といった数字のみが絶対的指標として扱われる組織では、ブランディングの余地はほとんどありません。数字がすべてを語る世界では、どれだけ他者からの見え方を整えても、メトリクスが未達であれば問答無用で弾かれます。
極めて有効な環境：「行動評価」「プロセス評価」が含まれる組織
一方で、多くのソフトウェアエンジニア組織が採用している次のような制度下では、セルフブランディングは極めて強力な武器になります。
- コンピテンシー評価 / バリュー評価： 「組織のバリューを体現する行動を取っていたか」「技術的なリーダーシップを発揮したか」といった定性的な行動を評価する制度。
- グレード制（等級制度）： 次のグレードに上がるための要件として「他チームへの技術的影響力」「組織全体の生産性向上」などが明文化されている制度。
- 360度評価（多面評価）： 同僚や関連部署からの定性的なレビューが査定に直接影響する制度。
こうした定性・プロセスの要素が含まれる場合、評価者の「主観」と「認知」が合否の決定打になります。そして主観と認知を望ましい方向にコントロールする技術こそが、セルフブランディングに他なりません。
5. 評価は「コードの外側」で決まる
エンジニア組織において、「技術力さえあれば評価されるべきだ」という言説は心地よく響きます。しかし、組織がスケールし、合議によって人が人を評価するフェーズに入った瞬間、その純粋主義は機能しなくなります。
評価とは、自分がどれだけ頑張ったかではなく、他者がその働きにどれだけの価値を感じたかという「認知の総量」で決まります。
自分の仕事の価値を適切に認知させ、評価会議で援護射撃を得るための下地を整えておくこと。それは小手先の処世術ではなく、エンジニアが組織の中で自らの影響力を最大化し、適切な権限と報酬を獲得するための必須スキルと言えます。